RBAC Persona Configuration

1. Introduction

A Persona is a bundled management role that grants access to various components of the EmpowerID platform. To configure a Persona properly, it is essential to understand its purpose and how it will be used.

• Access Considerations
  Which components of the system should they have access to? It is possible to grant access to the EmpowerID legacy platform or microservices such as Resource Admin, My Tasks, IAM Shop, and others.

• Visibility Restrictions
  Which objects should be restricted from their view? For example, you can restrict the visibility of specific applications the Persona can see in Resource Admin or limit the Persons/Groups they can manage.

• Dependencies and Inheritance
  What are the possible dependencies? Can users have multiple management roles, such as a standard employee role inherited from their business role, location, or group membership? Personas often inherit basic access levels based on an employee's type or group membership.

2. Management Role Configuration

Depending on the complexity and reusability of the Persona, the management role can be created using either a predefined Management Role Definition (serving as a template for reusable access) or a blank one (suitable for simpler, more focused roles). Only create a custom role if the preconfigured ones do not meet your requirements. The best practice is to create a management role bundle per persona that grands all required management roles (UI-, ACT-, VIS-). If a user has visibility over an object, it applies to all screens except for the IAM Shop (which does not have a default mode). To grant access to specific system components, you can add them either through RBAC or by assigning additional Management Roles.

2.1 Add Access via Actor RBAC Access

In the Management Role details, click the + button to add new resources directly or by location. In the example below, the user is adding the ResetAccountPassword workflow directly to a management role. In the example below, the user is adding the ACT-Group-Create Access Level by location to a management role.

The commonly used RBAC relation types are Direct, Relative, and By Location.

Direct

You can add a specific Access Level or resource to the management role. There are various resource types you can add, with commonly used ones including Controls, APIs, Workflows, and Pages.

Controls - These must be added with the Viewer access level. This grants specific access to certain UI components (protected app resources). For example, data-protectedsubcomponent="ITShop-TargetSystem-Control" provides access to the Target System filter in IAM Shop.

API - APIs are used with the Executor access level to grant access to backend services related to specific actions. For example, Nation API must be added to enable the loading of the country list in workflow forms.

Workflows - These are used with the Initiator access level. Advanced operations with specific parameters, where data can be provided through forms, are referred to as Low-Code workflows. For example, the Onboard Az Local Right workflow allows the addition of new App Rights.

Pages and Reports - These are used with the Viewer access level. To view specific pages in the system, access must be granted. For example, the EditGroupPage provides access to the Edit Group details page in the legacy admin platform.

Relative

Primarily used with ACT or custom ACT access levels for different resource types. It allows you to grant access to the owners or responsible parties of applications or specific resources (e.g., groups, app rights).

For example, you can assign the ACT-Local-Right-Assignment-Management access level to the Local Right resource type with various relative options:

• Local Right in Applications I am responsible for - In this case, a user who is the responsible party for a specific application will receive ACT-Local-Right-Assignment-Management access for all Local Rights (App Rights) within that application.
• Local Right in Applications I am RBAC owner for - Grants ACT-Local-Right-Assignment-Management access to users designated as RBAC owners for specific applications.
• Local Right I am responsible for - Provides access to users who are responsible parties for specific Local Rights.
• Local Rights I am RBAC owner for - Grants access to Local Rights for which the user is the RBAC owner.

By Location

This is primarily used with ACT or custom ACT access levels for different resource types.

To grant access to all users, select Default Organization as the location. Alternatively, you can restrict ACT access to a specific location within the location tree, such as Country, Department, or Plant.

Other

Other options like Belonging to which Group, Belonging to which Management Role, or Belonging to which Query-Based Collection can also be used similarly to By Location.

The difference is that instead of assigning access to people in a specific location, you assign access to people who are members of specific Groups, Management Roles, or Query-Based Collections.

2.2 Connect other management roles through Management Role Grants These Additional Management Roles.

Management roles can be added to other management roles, allowing them to inherit access. The parent Management Role gains all access levels (APIs, UI controls, workflows, pages) from the added management roles.

Example Management Role Types

• VIS - UI visibility access (e.g., VIS-Groups-All, VIS-Location-All).
• ACT - Actions that can be performed on specific resources (e.g., ACT-Location-CanUseInAssignments-All, ACT-Azure-Claims-Mapping-All).
• UI Feature Set - Groups access to specific UI components (e.g., UI-Res-Admin-MS-Common).

3. Management Role definition configuration

In the Management Role definition details, you can find the shipping access, which represents the default access shipped for this management role. You can enable or disable it.

In Management Role Definitions access via Actor RBAC can be added/removed in a similar manner as in management roles (direct, relative, or by location). Common UI controls, APIs, and workflows can be included in management role definitions, allowing them to be inherited by various child management roles.

4. Custom Access Levels

Access Levels contain operations. If the default Access Levels cannot be used because they include too many operations, consider creating a custom Access Level that includes only the operations you need.

5. Testing

Once a bundled management role is configured, changes may take some time to be reflected in the system. It is advisable to wait a few hours. In more complex client environments, it may take up to a day for the changes to be fully applied.